Nowadays, an Internet Protocol (IP) network is developing toward the direction of multi-service, and needs to support multiple services such as Next Generation Network (WIN), 3rd-generation (3G), Internet Protocol Television (IPTV) and data services. The IP network serves as a bearer network in an entire network. Compared with a conventional data service, a multi-service network, is quite demanding on reliability of the bearer network, and service reliability has gradually become one of the core competitiveness of data communications equipment.
In a router or a layer-3 switch of an IP or a Multi-Protocol Label Switch (MPLS) core network, the service reliability may be implemented through technologies such as a routing protocol, Graceful Restart (GR), Fasi Reroute (FRR), or Traffic Engineering (TE) protection group. On an Ethernet Lanswitch of a layer-2 network, the service reliability may be implemented through layer-2 redundancy protocols such as a Spanning Tree Protocol (STP), a Rapid Spanning Tree Protocol (RSTP) or a Multiple Spanning Tree Protocol (MSTP).
A service node in a convergence layer or an edge layer needs to support inter-device two-node cluster hot backup (inter-chassis/inter-node redundancy). An existing method for two-node cluster hot backup includes: configuring a redundancy protocol at access ports of two nodes for negotiating active/standby ports of the access ports, triggering service protection switching in the case that a peer port has a failure; and triggering service revertive switching after a primary node is restored. The two nodes synchronize user information (session-info or user-info) with each other through a certain protocol, so as to ensure that when an entire node has a failure or a link has a failure, a backup node has adequate information to quickly restore a service.
Apart from implementing the redundancy protocol and user information synchronization, a two-node cluster backup solution also needs to solve a problem of forwarding a traffic from the core network to a user, namely a downstream traffic, in various failure scenarios (including a link failure, a port failure, a line card failure, an entire node failure and service revertive switching).
An existing solution solves the problem of forwarding the downstream traffic through releasing or withdrawing a route.
For example, a network segment can only be applied at one access port; when the access port is promoted to an active access port, a node where the active access port is located releases a route of the network segment; and when the access port is switched from the active access port to a standby access port, the route of the network segment is withdrawn.
In the solution, after service switching or service revertive switching due to a failure, the downstream traffic cannot be restored to a normal state until the route is converged. Route convergence time is mainly decided by a routing calculation interval of the routing protocol. If the routing calculation interval is configured too short, a load of a Central Process Unit (CPU) of a router is increased; and if the routing calculation interval is configured too long, the route convergence time is prolonged accordingly, which goes against quick restoration of the service. In addition, for a service node, an IP address network segment is usually allocated globally, or allocated according to services. If it is restricted that one IP network segment can only be applied at one access port, user addresses are wasted, and at the same time, service deployment is difficult.
In another solution, a node releases a host route of an online user; when the user is online at an access port, a node where the access port is located releases the host route of the user; and when the access port where the user is located is switched to a standby state, the host route of the user is withdrawn. This manner supports a global application of the network segment at the node. However, this technology also has a route convergence problem: After service switching or service revertive switching due to a failure of the user, a service of the user cannot be restored to a normal state until the route is converged. In addition, because the host route of each user needs to be released, requirements on a hot backup node, and a routing capacity and performance of another router in the network are high. During service switching or service revertive switching due to a failure, the node needs to release or withdraw the host route of each user, which brings a great impact on the hot backup node, and CPUs of another router and a layer-3 switch in the network.